Access to the site using a key. Protection from uninvited guests in I2P

DDoS (denial of service) attack is a common model for harassing competitors. Its simplest option is to maximize the load on the network channel, so that real users either cannot reach the server or experience annoying delays. A more sensible approach is to artificially load services that readily consume server resources. For example, a barrage of queries causing database calls and other resource-intensive computing operations that overload the machine.

There are many services whose task is to protect clients from suspicious network activity from the outside. As a rule, they open and analyze even encrypted traffic, and also perform some analytical actions on the user’s browser to be sure to recognize the malicious load. As a result, the attacker receives a captcha or is not able to access the target resource at all..

What to do with hidden networks where users do not have an IP address, and analysis of encrypted traffic is unacceptable at the technology concept level? In this article, we will look at a unique method of protecting against DDoS attacks on an I2P network and, in general, we will analyze the technology of LeaseSets with authorization.

The material of the article is a logical continuation of the topic about encrypted LeaseSets, which serve as an additional privacy tool for a hidden resource. To communicate with an anonymous site, the I2P router turns to a certain reference node, which returns a LeaseSet - information about encryption keys and incoming service tunnels. This means that the holder of a floodfill (reference node) can learn about your resource by simply observing the LeaseSets that have published on it. Using an encrypted LeaseSet prevents this possibility.

A human-readable short address in the “.i2p” zone cannot be associated with such a resource, so the option is not widely applicable, but is used only when truly necessary. However, it would be illogical to settle on an encrypted LeaseSet: what if you hide your resource, but in the end its address is revealed by one of the trusted users? As a result, it turns out that the private service that the administrator tried to hide again falls under a possible DDoS attack and other theoretical troubles.

The apogee of the topic is an encrypted LeaseSet with authorization, which can be decrypted if you have a personal key in addition to the full address. This concept is unique of its kind because... allows the administrator to protect himself from malicious users at the network protocol level.

Just think about it: protection from all kinds of attacks is not done by a firewall, server settings, captchas and other third-party services, but at the level of the network itself. A user not authorized by the administrator will not be able to access the server because he has not received the LeaseSet, which stores information about the incoming tunnels of the hidden resource. Therefore, there can be no talk of any attacks - the resource exists beyond the attacker’s reach.

The I2P protocol provides two types of LeaseSet authorization: by password and by key. Password is a simpler method, but not much more difficult than using real cryptography. Security keys are many times superior to passwords, as they exclude even the speculative possibility of successful brute force. Passwords for a respected gentleman are bad manners.

From words to deeds

Encryption keys are generated by the client, after which the public key is communicated to the administrator of the target resource. The server encrypts the LeaseSet with each public key from the list. When receiving an encrypted LeaseSet, the user tries to use his private key. If the user's public key was not used during encryption, the LeaseSet remains undisclosed.

The minimum configuration of a tunnel with an encrypted license and authorization looks like this:

[SUPER-HIDDEN-SERVICE]
type = server
host = 127.0.0.1
port = 8080
inport = 80
keys = site.dat
signaturetype = 11
i2cp.leaseSetType = 5
i2cp.leaseSetAuthType = 1
i2cp.leaseSetClient.dh.NNN = User:PublicKey

IN parameter i2cp.leaseSetClient.dh.NNN = User:PublicKey

• NNN – random integer (needed to specify multiple keys)

• User – user name or nickname for the convenience of the administrator (you don’t have to specify)

• PublicKey – public key in base encoding64

Lizsets with authorization use x25519 encryption keys, which can be obtained using the utility of the same name in i2pd-tools.

In the client tunnel, that is, on the user side, you only need to specify one additional parameter i2cp.leaseSetPrivKey = PrivateKey, containing a base-encoded private key64.

To make the experiment clearer, I commented out the key on the client side and restarted the I2P router. No matter how long I wait, my computer cannot find the incoming tunnels of the specified endpoint. If you monitor the operation of the router at the debug level, you can see that the LeaseSet still arrives. However, its contents will remain a mystery..

Similarly, a restriction can be imposed by a resource administrator. If an offended user wants to bring heavenly punishment on the damned admin, he will not succeed. Even knowing the address won't help..

Currently, the option with authorization is only available for individual tunnels. The main user proxy, usually used for web surfing, does not have the parameter. However, such an opportunity should appear in the near future. This will allow you to use private resources without additional hassle, just by specifying your key once in the main configuration file of the router.